Giriic^ie  Mellon 

Software  Engineering  institute 


Pittsburgh,  PA  15213-3890 


SSAccKMStion 

Recorisiclering  the  Role  of  Systems 
Ehgineering  in  DoD  Software 
Problems 


GradyCarrpbell  (^Tagsa.cmj.edu) 


Sponsored  by  the  U.S.  Department  of  Defense 
©  2004  by  Carnegie  Meiion  University 


page  1 


Report  Documentation  Page 

Form  Approved 

0MB  No.  0704-0188 

Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 

VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  0MB  control  number. 

1.  REPORT  DATE 

JAN  2004  2.REPORTTYPE 

3.  DATES  COVERED 

00-00-2004  to  00-00-2004 

4.  TITLE  AND  SUBTITLE 

SIS  Acquisition:  Reconsidering  the  Role  of  Systems  Engineering  in  DoD 
Software  Problems 

5a.  CONTRACT  NUMBER 

5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

6.  AUTHOR(S) 

5d.  PROJECT  NUMBER 

5e.  TASK  NUMBER 

5f.  WORK  UNIT  NUMBER 

7.  PEREORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Carnegie  Mellon  University^Software  Engineering 

Institute, Pittsburgh, PA, 15213 

8.  PEREORMING  ORGANIZATION 

REPORT  NUMBER 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

10.  SPONSOR/MONITOR’S  ACRONYM(S) 

11.  SPONSOR/MONITOR’S  REPORT 
NUMBER(S) 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

14.  ABSTRACT 

15.  SUBJECT  TERMS 

16.  SECURITY  CLASSIEICATION  OE:  17.  LIMITATION  OE 

ARSTRAUT 

18.  NUMBER  19a.  NAME  OE 

OE  PAGES  RESPONSIBLE  PERSON 

a.  REPORT  b.  ABSTRACT  c.  THIS  PAGE  Same  aS 

unclassified  unclassified  unclassified  Report  (SAR) 

13 

Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std  Z39-18 


Oiriic^icMenoti 

Software  Engineering  institute 


Basic  Questions 


Are  any  software  problems  in 
DoD  acquisitions  traceable  to 
systems  engineering  practices? 

Would  reformulating  systems  engineering 
and  its  relationship  to  software  engineering 
reduce  problems  with  software? 
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Background/Motivation 

The  DoD  focus  on  acquiring  software-intensive  systems 

Lack  of  software  guidance  in  systems  engineering  sources 

Experiences  in  working  with  software  organizations  that 
information  from  systems  engineering  is  often  inadequate 

Experiences  with  software  product  lines  showing  that  most 
software  product  diversity  traces  to  system-level 
information  and  tradeoffs 
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The  Immediate  Context 

Systems  engineering  is  the  guiding  technical  approach  for 
DoD  acquisition  programs 

Systems  engineering  analyzes  operational  needs  to  define 
and  create  an  enhanced  operational  capability 

Systems  engineering  specifies  required  system  behavior 
and  decomposes  the  system  into  subsystems 

Systems  engineering  is  a  primary  conduit  and  filter  for 
information  to  subsystem  developers 

Software  engineering  is  seen  as  a  specialized  discipline 
focused  on  constructing  software  subsystems 
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Significance 

Any  reasonably  complex  system  has  software  as  a  critical 
element 

Software  is  always  part  of  a  broader  system 

Systems  and  software  decision  making  are  interdependent 
and  need  shared  visibility: 

•  Systems  decisions  constrain  software  alternatives 

•  Software  decisions  can  significantly  affect  the  emergent 
properties  of  a  system 

Systems  engineering  and  software  engineering  need  to 
overcome  a  conceptual  incompatibility  (physical  versus 
information  views  of  a  system) 
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Perceived  problems  for  software 

Lack  of  clear  and  complete  information  on  needs 

Failing  to  consider  software  properties  and  implications  in 
system-level  designs  and  trade  studies 

Software  decisions  (“after”  systems  engineering)  that 
affect  system  properties 

Systems  engineering  decisions  that  unnecessarily  limit  or 
complicate  software  alternatives 

Poor  fit  of  a  top-down  systems-software  process  to  actual 
objectives  (diverse  or  changing  requirements) 
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Relevance  to  DoD 


DoD  buys  systems  but  software  is  both  a  critical  enabler  and  a 
prominent  source  of  risk  (both  product  and  process) 

Systems  engineering  practices  contribute  to  software  risks  if 
they: 

•  Prematurely  over-constrain  software  engineering  choices 

•  Inadequately  communicate  information,  including  unknowns 
and  uncertainties,  needed  for  effective  software  engineering 

•  Fail  to  adequately  represent  and  analyze  the  implications  of 
software  design  choices  in  system-level  trade  studies 

Attempting  to  fix  software  engineering  problems  without 
rethinking  the  role  of  systems  engineering  may  limit  any  potential 
for  improvement 
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Questions  for  Further 
Investigation 

•  Are  perceived  problems  of  systems-software 
interdependencies  and  conflicts  real  and  pervasive? 

•  Are  there  reasonable  refinements  or  alternative 
reformulations  of  systems-software  engineering  that 
might  reduce  software  problems? 

•  Could  systemic  reform  of  the  systems-software 
engineering  process  and  practices  and  applicable  DoD 
policy  produce  improved  results  for  acquisition? 
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Some  Goals  for  System-Software 
Interdependence 

•  System-software  requirements  and  designs  are  iteratively 
refined 

•  Systems  engineering  applies  software  expertise  to  identify 
and  evaluate  alternative  system  decompositions 

•  Estimations  of  system  attributes  account  for  how  software 
decisions  can  affect  emergent  properties 

•  Human  interface  requirements  reflect  current  software 
capabilities 

•  Information  on  uncertain  and  changing  needs  is 
communicated  to  guide  designing  for  change 
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Prospective  Reformulations  of 
Systems-Software  Engineering 

(or  transitional  stages) 

•  Improve  systems  engineering  performance  by  refining 
current  methods  &  maturing  their  use  in  practice  (e.g.,  CMMI®) 

•  Apply  software  practices  in  systems  engineering  to  identify 
and  analyze  alternatives  and  system-level  implications 

•  Closely  integrate  and  iteratively  apply  systems  and  systems- 
level  software  engineering  for  analysis  and  design 

•  In  systems  engineering,  build  a  system  first  as  an  abstract 
computation  over  an  information  model  of  the  enterprise  - 
substitute  hardware  for  software  as  needed  to  optimize  and 
deploy 
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Related,  Advanced  Topics 

Process  improvement 
Hardware-software  co-design 
Product  lines  and  mass  customization 
Modeling  and  emulation  of  hardware  in  software 
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A  Call  for  Discussion  and  Action 

•  Share  perspectives  and  perceptions  of  software¬ 
intensive  systems  engineering 

•  Report  on  alternative  system -software  relationships  in 
theory  or  practice 

•  Pursue  answers  to  ‘questions  for  further  investigation’ 

•  Initiate  efforts  to  collaboratively  reformulate  systems 
engineering  for  SIS  or  revise  DoD  policy  accordingly 
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